Date: Wed, 24 Aug 94 04:30:19 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #283 

To: Ham-Digital 


Ham-Digital Digest Wed, 24 Aug 94 Volume 94 : Issue 283 


Today's Topics: 
(none) 
Filters for TEKK's 
HF Packet 

MFJ 1278 - looking for software 
MS400 4 port serial settings? 

paKet6 Manual 

PKTMON12.LZH 

Will my radio work as a packet station??? (2 msgs) 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 23 Aug 94 14:27:00 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: (none) 

To: ham-digital@ucsd.edu 


signoff ham-digital 


Date: Mon, 22 Aug 1994 10:58:58 -0400 

From: ftpbox!mothost! 1mpsbbs!NewsWatcher!user@uunet.uu.net 
Subject: Filters for TEKK's 

To: ham-digital@ucsd.edu 


In article <CuqGHw.7EK@nntpa.cb.att.com>, jkbe@lena (John Bednar) wrote: 


> I am looking for suppliers that sell 21.4 Mhz IF crystal filters 
> that I can stuff into a TEKK data radio. I'd like to experiment 
> with higher data rates. Has anyone been through this before? 

> 

> John, WB3ESS 

> aljkbe@attme.att.com 


Try Piezo Technology (Technologies??) in the Ft. Lauderdale, FL area. 
Sorry, I don't have their phone number, but LD information for Area Code 
305 should be able to find it for you. As of a few years ago they had 
filters for both 10.7 and 21.4 in several different bandwidths and options 
for sharp skirts or minimal passband ripple. At that time they were the 
best US supplier I could find for such goodies. 


Karl Beckman, P.E. < If our English language is so > 
Motorola LMPS.RNSG.Analog Data < precise, why do you drive on the > 
(Square waves & round corners) < parkway and park on the driveway? > 
Opinions expressed here do not belong to or represent Motorola Inc. 
Amateur radio WA8NVW NavyMARS NNNOVBH @ NOGBN.NOAST 


Date: 23 Aug 1994 21:44:25 GMT 

From: newsgw.mentorg.com!wv.mentorg.com! hanko@uunet.uu.net 
Subject: HF Packet 

To: ham-digital@ucsd.edu 


In article <ZIELKE.94Aug22185246@sherlock-hemlock.muppets>, zielke@sherlock- 
hemlock.muppets (David Zielke) writes: 

|> I am in the process of examining the possibilities of using HF packet to 

|> provide communication between my sailboat while at sea and land based e-mail 
|> connections. I have been a ham since the late 70's and have been inactive 
|> for some time. Suggestions of what kind of gear (HF rig, TNC, computer) 

|> would be very helpful. I will most likely be loading the backstay as an 

|> antenna. 


Plan to use amtor, pactor, clover, gtor, or clover. 
Packet on HF is not actually very useful. 
CLOVER is best, with the other protocols working well also. 


|> Also, I am trying to decide between Intel based PC's and the Mac portables 
|> (something like a 540 active monochrome in the mac line or a 486 33mhz 
|> laptop in the intel world). 


DOS/Windows Laptop. MUCH software available for it, minimal software 
available for any other computer. 


If you end up using CLOVER, I'll see you on HF ... 


Hank 


Hank Oredson @ Mentor Graphics Library Operations 
Internet : hank_oredson@mentorg.com "Parts 'R Us!" 
Amateur Radio: WORLI@WORLI.OR.USA.NOAM 


Date: 24 Aug 94 14:55:24 GMT 

From: news-mail-gateway@ucsd.edu 
Subject: MFJ 1278 - looking for software 
To: ham-digital@ucsd.edu 


Hi and tnx reading this, 

I am using an tne 1278 from MFJ for some days by controlling the exellent 
xp-terminal. I works well, but I would like to try some other software 
especially for fax and sstv too. Is there someone who can give me hint where 
I can find it i would be pleased. 

tnx in advance es 73 de Wolfgang (DL7VWH) 


Technische Universitaet Berlin 17% 
Institut fuer Bergbauwissenschaften, Sekr. BH 3 t/i 
Str. des 17. Juni 135, 10623 Berlin, Germany 

Wolfgang Heise - VOICE: #HF49-30-31425672 - FAX: ..-31426797 


possible on hamradio/packetradio too by DL7VWH@dbOgr.bln.deu.eu 


Date: 23 Aug 1994 00:54:30 GMT 

From: munnari.oz.au!yarrina.connect.com.au!harbinger.cc.monash.edu.au! 
news.cs.su.oz.au!news.adelaide.edu.au!mayfield@uunet.uu.net 

Subject: MS400 4 port serial settings? 

To: ham-digital@ucsd.edu 


Does anyone have some docco on the MS400 PC 4 port serial card, as to the dip 
switch settings for each port ? Ive worked a few out, but some have me bluffed, 
also any info on whether the card is capable of interrupt sharing ? 


thanks ... Rob 


rob mayfield senior technical analyst, australian submarine corporation p/1 


mayfield@wattle.itd.adelaide.edu.au vk5xxx@vk5xxx.d#adl.#sa.aus.oc +6183487713w 


Date: Tue, 23 Aug 1994 22:06:33 +0000 

From: ihnp4.ucsd.edu!dog.ee.1lbl.gov!overload.1lbl.gov!agate!howland.reston.ans.net! 
europa.eng.gtefsd.com!emory!metro.atlanta.com!mhv.net!news.sprintlink.net!demon! 
g1ixgp.demon.co.uk! g1xgp@@. 

Subject: paKet6 Manual 

To: ham-digital@ucsd.edu 


AAPRA the Australian Packet Radio Group have published a Booklet Manual 
of Tony Lonsdale's (VK2DHU) acclaimed paket 6 program. AAPRA have 
appointed Essex Packet Shareware to acts as their UK Agent. Anyone 
interested in obtaining a copy/information, kindly contact the 
undersigned: - 


paket@g1xgp.demon.co.uk 


73 
Steve 


+ Steve Blinkhorn + G1XGP @ GB7WIG.#34.GBR.EU (Amateur Radio) + 
+ AMPRnet + g1xgp@g1xgp.ampr.org [44.131.16.147] + 
+ Essex Packet Group + g1xgp@g1xgp.demon.co.uk (Internet) + 


Date: Tue, 23 Aug 1994 08:45:38 

From: elroy.jpl.nasa.gov!usc!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com! 
sislnews.csc.ti.com!ken_durham.linear.sc.ti.com!ken@ames.arpa 

Subject: PKTMON12.LZH 

To: ham-digital@ucsd.edu 


PKTMON12 is supposedly a program to allow reception of packet radio signals 
without an external TNC or multimode controller. It gets its input from the 
radio speaker output through an op-amp attached to the PC serial port. 

The signal is decoded and displayed on the Hamcom program terminal screen. 
Both programs are shareware, but PKTMON12 was hard to find. I finally got it 
by ftp from funet.fi. The problem is that the program is compressed and has 
a suffix of LZH. 


If anyone can tell me where to obtain a copy of whatever decompression 
program is required for LZH, I would appreciate it. 


de K5MBV 


PS. My email should be working now. 


Date: 23 Aug 1994 10:06:09 -0400 

From: newstf£01.cr1.aol.com!search01.news.aol.com!not-for-mail@uunet.uu.net 
Subject: Will my radio work as a packet station??? 

To: ham-digital@ucsd.edu 


I have a Baycom modem that I got from A&A engineering. I wish to hook it 
up to one of my radios to run packet but I have heard that some radios do 
not switch fast enough from transmit to receive? My possible radios are: 
Azden PCS-3000 

Yaesu FT-207R 

Icom 02-AT 

Standard SR-C146A 


Will any of these radios work without modification? 
If not, can they be modified to work? 
Please e-mail JoeSullivn@AOL.com 


Date: Tue, 23 Aug 1994 21:45:59 GMT 

From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!news.cac.psu.edu! 
ppp35.cac.psu.edu! cwm3@network.ucsd.edu 

Subject: Will my radio work as a packet station??? 

To: ham-digital@ucsd.edu 


In article <33cvoh$3n4@search01.news.aol.com> joesullivn@aol.com (JoeSullivn) 
writes: 

>From: joesullivn@aol.com (JoeSullivn) 

>Subject: Will my radio work as a packet station??? 

>Date: 23 Aug 1994 10:06:09 -0400 


>I have a Baycom modem that I got from A&A engineering. I wish to hook it 
>up to one of my radios to run packet but I have heard that some radios do 
>not switch fast enough from transmit to receive? My possible radios are: 
>Azden PCS-3000 

>Yaesu FT-207R 

>Icom 02-AT 

>Standard SR-C146A 


>Will any of these radios work without modification? 
>If not, can they be modified to work? 


>Please e-mail JoeSullivn@AOL.com 
Hi Joe. 


I am sure the Azden, Yaesu, and Icom will work just fine. In fact, I 
sometimes use my IC-O2AT on packet. I'm not sure about the Standard but 
don't think it would have any problem. In general, any rig will work but 
those with solid-state T/R switching are preferred. Some rigs may require 
some adjustments to certain TNC parameters but that turns out to be no big 
deal. 


73, Chuck - K3CM 


Date: Tue, 23 Aug 1994 16:48:17 GMT 
From: world! dts@uunet.uu.net 
To: ham-digital@ucsd.edu 


References <32d90d$2gg@vixen.cso.ui, <3306v8$jbi@vixen.cso.uiuc.edu>, 
<1994Aug20.143652 .9960@ke4zv.atl.ga.us> 
Subject : Re: Looking for DXCluster software 


In article <1994Aug20.143652.9960@ke4zv.atl.ga.us>, 

Gary Coffman <gary@ke4zv.atl.ga.us> wrote: 

>In article <3306v8$jbi@vixen.cso.uiuc.edu> k9cw@prairienet.org (Andrew B. White) 
writes: 

>>While I agree with you that PC use of AX.25 is not the best for distributing 
>>spots, it is, currently, the only game in town. 

> 

>Note that broadcast servers us AX.25 too, just UI frames instead of 
>connected mode frames. The FCC has us locked into AX.25 wrappers for 
>unattended third party use. 

> 

>>AK1A has something like 

>>400 nodes installed around the world, and they all talk to each other (altho 
>>the email facility comes close to being useless if the mail has to go more 
>>than one hop). Besides, if the network is configured as it should be, 
>>with local users on one frequency and the inter-node link on another, I 

>>am not sure that the amount of bandwidth required is an issue. 

> 

>While splitting the users off the backbone is essential to making the 
>systems work well at all, it xdoes*x increase the amount of bandwidth 

>the systems tie up. The real problem is that connected mode bulletin 
>distribution uses nearly 26 times the channel capacity of a broadcast 
>server. That means in practice, at our current low channel speeds, that 
>channels have to be xdedicated* to Packet Cluster activity rather than 

>being timeshared with other packet uses. That's bad spectrum utilization. 


> 

>Of course faster channel speeds can help, and I note with approval 

>that Packet Clusters seem to be among the first to embrace faster 
>channel speeds (out of necessity), first jumping to 2400 baud and 

>now going to 9600 baud. But that's only a less than 2 and less than 

>9 increase in channel capacity respectively at best (actually much 
>worse than that on a simplex frequency due to turnaround and overhead 
>delays). But a simple change to a broadcast protocol would ximmediatelyx 
>give a nearly 26 fold increase in available channel capacity. Since it's 
>xonly softwarex (heh), the change could be relatively quick and painless 
>too. 

> 

>Note, broadcast use would free up channels only by allowing more 

>than 26 stations per cluster. The channel would still have to be 
>dedicated to the broadcast server. But the server could also serve 

>more than just DX spots with the excess channel capacity. It could 

>also distribute other types of bulletins and files in it's idle 

>time. 

> 

>I don't think most connected mode servers are a good use of packet 
>resources any longer. Broadcast servers are so much more efficient 

>that Cluster xand*x BBSs should change over as rapidly as practical. 
>There remain some cases where connected mode works best, like serving 
>low density WANs that need digis to get coverage. For higher density 
>areas, however, the broadcast server is very much superior for most 
>uses. (Personal Email may remain an exception.) Perhaps we need to 
>think about making broadcast the bulletin and file distribution default, 
>and connected mode the exception, in future server designs. 


Gary, I assume then that you favor the discontinuance of using TELNET and 
FTP on top of TCP/IP in favor of a broadcast or multicast equivalent? 


The big problem I see with "simply" replacing the use of connection- 
oriented packets with UI frames for DX clusters is one of reliability. 
Packet is an extremely UNRELIABLE data link. That has to be factored 

in to any change which is made. There's nothing wrong with running over 
unreliable media, you just have to account for that in higher level 
protocols. At some point in the stack you must acknowledge frames, or 
recognize (in the broadcast case) that you've missed frames, and ask 
for repeats. 


How is the PacketCluster machine to know that the UI frame with a DX 
spot just got stomped by another station starting to transmit a frame? 
Packet radio does NOT run with Collision Detection in the way that 
Ethernet does. You cannot tell, when transmitting, that your frame 

has just gotten munched. 


Dan 


Daniel Senie Internet: dts@world.std.com 
Daniel Senie Consulting nijeb@world.std.com 
508-779-0439 Compuserve: 74176 ,1347 


Date: 23 Aug 1994 01:31:09 GMT 

From: agate! howland.reston.ans.net!vixen.cso.uiuc.edu!prairienet.org! 
k9cw@ames.arpa 

To: ham-digital@ucsd.edu 


References <1994Aug18 .144706.28341@ke4zv.atl.ga.us>, <119955@cup.portal.com>, 
<32b56i$0t5@T 

Reply-To : k9cw@prairienet.org (Andrew B. White) 

Subject : Re: Looking for DXCluster software 


In a previous article, gary@ke4zv.atl.ga.us (Gary Coffman) says: 


>While splitting the users off the backbone is essential to making the 
>systems work well at all, it *does* increase the amount of bandwidth 
>the systems tie up. 


But if we move these users to another band (222/440/900 or whatever) we can 
re-use the bandwidth, and accommodate the current users given current 
equipment. 


I am confused about how the broadcast server works. Does each end-point 
periodically transmit a poll to see if any messages were missed? Or is 
the assumption made that every end-point receives every broadcast error 
free? With UI frames, does each end-point "guess" whether the broadcast 
was from the broadcast server base on what can be recovered from a 
corrupted frame? Does the broadcast server continuously repeat the last 
N spots? 


PacketCluster presently provides more than just spot information, 

but the DX spots are the most important. Without the ability for each 
end-point to confirm receipt or request fills, it seems to me we have no 
better a system than the old 2m voice net (actually not quite that bad) or 
the 2m Baudot net we used to use in the 70's. If fill requests do not 
occur on the broadcast frequency, then we need a second channel for 

email transmission, listing old DX spots, searching the callbook, etc. 


How would that work with the broadcast server? 


73, Drew 


*- 


su Need «St. te ee a See Se a ae «Set AS ik. a = tent * 
internet: k9cw@prairienet.org | 
phone/fax: 217-643-7327 

at) ah am "i  A ) S- AM )La * 


Andrew B. White K9CW 
ABW Associates, Ltd. 


+ —— + 


Date: Mon, 22 Aug 1994 10:38:16 -0400 
From: ftpbox!mothost! 1lmpsbbs!NewsWatcher!user@uunet.uu.net 


To: 


ham-digital@ucsd.edu 


References <32d90d$2gg@vixen.cso.ui, <3306v8$jbi@vixen.cso.uiuc.edu>, 
<1994Aug18.200851.17094@nosc.mil> 
Subject : Re: Looking for DXCluster software 


In article <1994Aug18.200851.17094@nosc.mil>, craigr@n6énd.nosc.mil wrote: 


> 


In <3306v8$jbi@vixen.cso.uiuc.edu>, k9cw@prairienet.org (Andrew B. White) 


writes: 


VV VV VV VV VV VV VV VV VV VV VV VV VV VV 


> 
>In a previous article, gary@ke4zv.atl.ga.us (Gary Coffman) says: 

> 

>>Yes, $400 is excessive. It's excessive because cluster is such a bandwidth 
>>wasting kludge. (Ok, it's a xusefulx kludge, but kludge it is.) You can 
>>use free broadcast server software sending the info *2* times, one uplink 
>>and one broadcast (Pacsat protocol), instead of *27* to accomplish the 
>>same DX spot reporting. That's much more bandwidth friendly. Fills can be 


>While I agree with you that PC use of AX.25 is not the best for distributing 
>spots, it is, currently, the only game in town. AK1A has something like 
>400 nodes installed around the world, and they all talk to each other (altho 
>the email facility comes close to being useless if the mail has to go more 
>than one hop). Besides, if the network is configured as it should be, 

>with local users on one frequency and the inter-node link on another, I 

>am not sure that the amount of bandwidth required is an issue. 


I also agree that AX.25 is not the best protocol for sending DX spots but 
PacketCluster is an AX.25 application that requires the minimum equipment 

on the user end. A radio, TNC, and dumb terminal is the user investment. It 
would seem that to implement a more efficient protocol would certainly require 

a computer on the user end to sort things out. Some of the OF's barely mastered 
getting a dumb terminal to talk to a TNC, it would be real interesting watching 
them trying to become computer literate. Hi.. 


But if someone came out with a system that offered enough advantages over the 
current Cluster software, I think it might catch on. There are many problems 


> with PC that could be overcome by a more robust protocol which would be very 
> attractive to the sysops. My own feeling is that PacketCluster needs 
competition 

> or many of the problems with it are not going to be solved. 

> 

> Rick Craig, N6ND 

> craigr@marlin.nosc.mil 


Well, I'm no software writer or DX Cluster user, but I'm still a ham and we 
all offer opinions, solicited or otherwise. I'm NOT offering to write this 
update or even beta-test it, but let me toss one suggestion onto the pile: 
1) Take a look at the APRS software by Bob Bruninga WB4APR and note how he 
uses the beacon message to communicate location data without requiring 
"ack"s from every recipient. 

2) Apply the same idea to Packet Cluster, possibly fitting in some other 
improvements at the same time such as the APRS location. This would soothe 
Gary's very legitimate distress about packet channel loading. 

Any station beaconing in the proper format could be "logged in" to P-C if 
their APRS coordinates were within a reasonable distance of the P-C host 
area. Full 2-way connects would not be required unless the operator needed 
the FULL P-C BBS services; persons wanting only the DX spots could simply 
watch the beacons go by. In fact, that's what I do most of the time to 
avoid loading the PacketCluster frequency with unneeded acks, but it is 
frustrating to watch the same spot go by 64 times when P-C is fully 
occupied. 

3) I£ someone can convince K1EA and WB4APR to work together, I'll bet that 
each of them can find at least one more way to improve the combined 
software and two more applications that we haven't yet thought of. 

Synergy, cooperation, and talent arte a combination that is almost 
impossible to beat (unless your name is Bill Gates, anyhow!). 


Karl Beckman, P.E. < If our English language is so > 
Motorola LMPS.RNSG.Analog Data < precise, why do you drive on the > 
(Square waves & round corners) < parkway and park on the driveway? > 
Opinions expressed here do not belong to or represent Motorola Inc. 
Amateur radio WA8NVW NavyMARS NNNOVBH @ NOGBN.NOAST 


End of Ham-Digital Digest V94 #283 
KAKKKKKKKAKKKKKKKKKKKKKKKEKRKR AKA A 


